The first word is the key checksum. To learn how the checksum is produced, see the Checksum routine below. It is produced either by the encryption key or by both the encryption key and the scrambling key. The checksum is later deleted when it is checked and verified by the decryption routine.
The rest of the words are encrypted (and optionally scrambled and/or compressed) ASCII values. Note that two equal letters standing next to each other (i.e. "A" and "A") won’t have the same encrypted value, unless the key is one letter.
Some HCE files is only a checksum and a lot of gibberish - the gibberish is in fact numbers compressed using the letter compression technique (LCT). See below for more info.
Note: Filenames are not supported (not yet, anyway).
The encryption routine
First you must obtain a key. This can be whatever you want, but remember that it is CASE sensitive.
To encrypt a letter using the HCE encryption routine, a checksum must first be made from the key. If scrambling is used, the checksum of the scrambling key should be added to the checksum made from the encryption key. Then the letters in the key must be converted to ASCII. Each ASCII value must be separated from the others.
Example: The key "TestKey" will, without the quotes, become "84 101 115 116 75 101 121".
When this is done, the resulting ASCII values and the data to be encrypted is passed to a routine that uses the key to encrypt the data.
A counter with the value 1 is created. This is then incremented by one each time the routine loops until its value is equal to the number of words in the key (the number of ASCII values). It is then reset to 1. The routine then takes the ASCII value of char n of the data (a), word keyNum of the key (b), and keyNum (c) and uses the data like this (that is the formula for encryption!): ((a*b+c)*b+c) and then rounds the result to the nearest whole number. The number returned is written along with a space (" ") to a variable that contains the encrypted data. When all the letters have been processed like this, the last letter of the encrypted data is deleted (which should be a " ") before it is optionally scrambled and/or compressed. Then the data is written to a file. Note that for each letter that is encrypted, make sure you check that the encrypted letter is NOT zero (which is an irreversible letter. Try multiplying 0 with, say, 5 and you get 0. Try with 19745551215, and you’ll still get 0 (but you knew that...?)).
The formula for decryption is (((a-b)/c)-b)/c, where a is word n of the data. The number returned is the original ASCII value of the data, unless the key was wrong. Remember to first check the checksum, then delete it from the encrypted data before you begin to decrypt the rest of the data.
The scrambling routine
A scrambling key must be obtained. This key is also CASE sensitive. The key is then converted much in the same way as the encryption key, accept that you don’t separate the ASCII values.
Example: The key "TestKey" will, without the quotes, become "8410111511675101121".
A counter is then set up as in the encryption routine, and used in the same way, accept that it tells the computer what letter of the scrambling key is to be used, instead of which word. Then the routine gets the number of letters in word n of the encrypted data (x). If this number is above letter keyNum of the key, then a random number between 0 and 9 (only 1 and 9 in HyperCard) is placed after the letter x of word n of data. If the number is below or equal to letter keyNum of the key, the random number will be put after the last letter of the word. The scrambling routine then moves on to the next number. Note that using random numbers between 1 and 9 is preferred for numbers between 0 and 9, if compression is used.
To unscramble, use the same routine as above, but instead of adding a number, you delete the letter containing the number.
The checksum routine
The checksum routine is actually a slightly modified version of HC Checksum (also from YLS). It needs two params, cData and cSeed. CData is the data to create the checksum from (i.e. the key) and cSeed is the seed ("HCE" for encryption and "HCS" for scrambling, both without the quotes). CSeed is converted to ASCII values and each value is added to a variable. This variable is then moved to cSeed (replacing the old cSeed).
The final checksum is first set to 0. A counter is then set up. This counter has the value 1, and the is incremented by one each time the routine loops, until the value reaches 5, when it is reset to 1. Each time the routine loops, the ASCII value of letter n of cData is put into a temporary variable (x). Depending on the counter, one of the four basic arithmetical operations is performed in this order:
If the counter is 1 then add x*cSeed to the checksum.
If the counter is 2 then add x/cSeed to the checksum.
If the counter is 3 then add x+cSeed to the checksum.
If the counter is 4 then add x-cSeed to the checksum.
The checksum is then divided by cSeed/2 (formula: checksum/(cSeed/2)) and returned.
The letter compression technique
The letter compression technique (LCT) works by changing pairs of numbers into a letter (see the LCT alphabet below). LCT can compress a HCE file with compression rates up to 50% (most usual is 30-40%).
You take two numbers from the number 12345 67890. Then you find the number these two numbers form together (12, not 1+2), and convert it to its proper ASCII letter before you put it into (after) a variable called compData (or whatever). Then delete the two numbers the routine just compressed and continue like this until there are no more numbers to compress.
When the routine reaches a zero as the first letter of a two letter combination, a lower case d is used (for simplicity) and only the zero is deleted from the data. Each time a space (" ") occurs to separate numbers, a § (don’t ask) is used and put after compData before the space is deleted.
To decompress files compressed using LCT, do the exact same thing, accept replacing the letters with their ASCII values.
HC Encrypt recognizes compressed files by checking the first letter of the checksum. If it is a #, then the file is recognized as being compressed. So, if compression is used, remember to put a # in front of the checksum.
Example: If the checksum was 12345.67890 then the checksum would look like this if the file is compressed: #12345.67890. If the first letter of the checksum is ∞, HC Encrypt will stop trying to do anything with the file, as the resource fork of the original file is encrypted as well. Why? Because HC Encrypt doesn’t support resource fork encryption.
More info...
To understand more (or get more confused) on the workings of these routines, look at the scripts in HC Encrypt. If there is something illogical here that you can’t understand, notify me and I’ll try to fix it.
You can also add stuff like percentage calculation, remaining time estimation, a progress bar, etc. to the routines, as well as the ability to compress resource forks. If you decide to do so, put a ∞ (option-5) as the first letter of the checksum so HC Encrypt can recognize it, and decide against decrypting the file. If the file is compressed, the # goes after the ∞.
If you decide to add resource fork encryption, please notify me and send me a copy of the format, so I can standarize it through this document.
A plea for help
I have realized that HC Encrypt isn’t very good at large files due to HyperCards annoying speed, but the routines are (at least the way I see it) pretty good. Therefore, I would like help from any experienced programmer to create an application that uses the HCE standards. If you’re interested, contact me.
If you want to use any of them for your own encryption program (or whatever), you must pay me $0 for a freeware license (just notify me and give proper credit in your program), $40 for a shareware license and $150 for a commercial license. To contact me, send e-mail to Hakon.Stodle@kunst.hitos.no or mail me at this adress:
